Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-138.txt

Text File | 1994-12-08 | 42.3 KB | 1,197 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 13 Jul 92       Volume 1 : Issue 138

Today's Topics:

    Bug fix for window standard state code
    Faking CustomGetFile under 6.0.x
    Programming C++ on Mac
    XWindows (was - Towards what purpose A/UX?)
    SUMMARY: Comparing blocks of memory in Pascal



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

These digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Charles B. Cranston)
Subject: Bug fix for window standard state code
Date: 9 Jun 92 21:33:28 GMT
Organization: UM Home for the Terminally Analytical

Well, at the time I posted that code I explicitly said it
wasn't perfect, and it sure wasn't.  Sometimes it will zoom
to the wrong monitor.  Here's why:

Consider this heterogenous multiple-monitor setup (which happens
to be the setup I am using at work now):


+----------+ +-------------------------------+
|          | |                               |
|  Apple   | |        Micrographics          |
|   13"    | |         Megascreen            |
|  Color   | |            B/W                |
|          | |                               |
+----------+ |                               |
             |                               |
             |                               |
             |                               |
             |                               |
             +-------------------------------+

Now, suppose you have a window that is smaller than its natural
size and split between the monitors, with most of it on the left
(smaller) monitor (note area a is larger than area b).

+----------+ +-------------------------------+
|          | |                               |
|      ..........                            |
|      :aaa| |bb:                            |
|      ..........                            |
|          | |                               |
+----------+ |                               |
             |                               |
             |                               |
             |                               |
             |                               |
             +-------------------------------+

When you hit the zoom box, the code I posted will zoom to the
RIGHT monitor, rather than to the (expected) left monitor.

The reason for this bug is that the expanded natural size
rectangle is being used for the "monitor on which most of the
window resides" instead of the current window rectangle.


+----------+ +-------------------------------+
|          | |                               |
|      ..........                            |
|      :aaa| |bb:                            |
|      :aaa| |bb:                            |
|      :aaa| |bb:                            |
+------:---+ |bb:                            |
       :     |bb:                            |
       :     |bb:                            |
       ..........                            |
             |                               |
             +-------------------------------+


Note that area b is now larger than area a (because of the
greater intersection of the hidden window area with the
taller monitor) and so the wrong monitor is choosen.


Here is the corrected code:


/* Compute "standard state" for resizable (list) window.
 * This is used by the zooming stuff.
 */
getstdstate(WindowPtr windp, Rect *wrect)
{
    Rect    rect;
    GDHandle    thegd, maingd;

    getnaturalsize(windp,wrect);
    if (colorqd) {
    thegd = nil;
    getmonitor(TOPLEFT(*wrect),&thegd);
    if ( (nil==thegd) || !PtInRect(BOTRITE(*wrect),&(**thegd).gdRect) ) {
        thegd = maingd = GetMainDevice();
            getwindowrect(windp,&rect);    /* the fix */
        getmaxmonitor(&rect,&thegd);    /* the fix */
        rect = (**thegd).gdRect;
        rect.top += 16;
        if ( maingd == thegd )
        rect.top += GetMBarHeight();
        InsetRect(&rect,5,5);
        OffsetRect(wrect,rect.left-(*wrect).left,rect.top-(*wrect).top);
        if ( (*wrect).bottom > rect.bottom)
        (*wrect).bottom = rect.bottom;
        else
        OffsetRect(wrect,0,(RECTHITE(rect)-RECTHITE(*wrect))/3);
        if ( (*wrect).right > rect.right)
        (*wrect).right = rect.right;
        else
        OffsetRect(wrect,(RECTWIDE(rect)-RECTWIDE(*wrect))/2,0);
    }
    } else {
    rect = qd.screenBits.bounds;
    if ( !PtInRect(BOTRITE(*wrect),&rect) ) {
        rect.top += 16 + GetMBarHeight();
        InsetRect(&rect,5,5);
        OffsetRect(wrect,rect.left-(*wrect).left,rect.top-(*wrect).top);
        if ( (*wrect).bottom > rect.bottom)
        (*wrect).bottom = rect.bottom;
        else
        OffsetRect(wrect,0,(RECTHITE(rect)-RECTHITE(*wrect))/3);
        if ( (*wrect).right > rect.right)
        (*wrect).right = rect.right;
        else
        OffsetRect(wrect,(RECTWIDE(rect)-RECTWIDE(*wrect))/2,0);
    }

    }
}


Mea Bugga.

---------------------------

From: [e-mail] (Carl W. Haynes III)
Subject: Faking CustomGetFile under 6.0.x
Date: 26 May 92 18:20:30 GMT


I'm having some trouble duplicating CustomGetFile's functionality
under System 6.0.X -  Here's the deal:

I need to add a "New..." Button to the standard get dialog. Under
System 7, this is no problem, I call CustomGetFile(), fake a
cancel Button msg when New is selected and use the yourDataPtr
parameter to let me know what happened.

Under 6.0.X I use SFPGetFile() to display my new and improved
standard dlg. I can catch the selection of my New button with
a dlgHook and can fake the cancel button,
But I can't figure out a way to return the message that New was
actually selected rather then Cancel.

The two schemes I thought up are:

1) use a global. Easy way out, but messy in the long run. I'm
   trying to limit the use of globals and I would like a solution
   that is easy to cut and paste into other applications.

2) Stash the Boolean NewWasPressed into the copy field of the
   SFReply record (IM I-519 says this field is not used). I don't
   know how to get access to the record to stash the Boolean there
   and it will probably break in the future even if I do figure it
   out.

So..... any ideas? Lots of applications do this  (FileMaker Pro,
Think C, etc) so it can't be that hard. I have the feeling that
I'm making it harder than it actually is and that I'm missing
something completely obvious.

Any help is appreciated,
carl

- --
Carl W. Haynes III
Haynes Consulting Services        ||  [e-mail]
PO Box 2715                       ||  [e-mail]
W. Lafayette, IN 47906            ||  voice & fax: [phone]
- ----------------------------------------------------------------------
                  Macintosh Programming & Consulting

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 26 May 92 20:18:27 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.edu> [e-mail] (Carl W. Haynes III) writes:

   1) use a global. Easy way out, but messy in the long run. I'm
      trying to limit the use of globals and I would like a solution
      that is easy to cut and paste into other applications.

Aimple, clean, and the way Apple does it. Really.

   2) Stash the Boolean NewWasPressed into the copy field of the
      SFReply record (IM I-519 says this field is not used). I don't

Unused == DO NOT USE. Period.

Sometimes globals are necessary. Since the SFP is "nice" and
uses no messy interrupt/A5 stuff, you can use globals OK.

- --
h++ - new and improved !

A Bus Station is where buses stop. A Train Station is where
trains stop. On my desk, there is a Work Station.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: Wed, 10 Jun 92 09:35:17 EST
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jon W{tte) writes:
> Aimple, clean, and the way Apple does it. Really.
>
>    2) Stash the Boolean NewWasPressed into the copy field of the
>       SFReply record (IM I-519 says this field is not used). I don't
>
> Unused == DO NOT USE. Period.
>
> Sometimes globals are necessary. Since the SFP is "nice" and
> uses no messy interrupt/A5 stuff, you can use globals OK.

What about the Dialog Filter Approach. Define your own SFReply:

    struct MySFReply {
        SFReply        sfr;
        int            myflag;
        }

And passing the pointer to this structre to SFGetFile().
This way the SFReply structure is unadulterated, and you can
append any amount of data you want. You get the pointer in your
filter, and no globals.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 10 Jun 92 21:22:18 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Tim Endres) writes:
>
>
> In article <[e-mail]>
(comp.sys.mac.programmer), [e-mail] (Jon W{tte) writes:
> > Aimple, clean, and the way Apple does it. Really.
> >
> >    2) Stash the Boolean NewWasPressed into the copy field of the
> >       SFReply record (IM I-519 says this field is not used). I don't
> >
> > Unused == DO NOT USE. Period.
> >
> > Sometimes globals are necessary. Since the SFP is "nice" and
> > uses no messy interrupt/A5 stuff, you can use globals OK.
>
> What about the Dialog Filter Approach. Define your own SFReply:
>
>     struct MySFReply {
>         SFReply        sfr;
>         int            myflag;
>         }
>
> And passing the pointer to this structre to SFGetFile().
> This way the SFReply structure is unadulterated, and you can
> append any amount of data you want. You get the pointer in your
> filter, and no globals.
>

You know, sometimes I wonder if I'm missing something with this approach.
Someone else suggested it to me, and I fell for it. Only later did I remember
that the dlgHook is _not_ passed a pointer to the reply record. It is passed an
item number (which could be a psuedo-item number) and a DialogPtr.

Now you suggest the same thing, and I wonder if I'm missing something.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Josh Lam)
Subject: Programming C++ on Mac
Date: 27 May 92 17:39:46 GMT
Organization: Honeywell Air Transport Systems Division

Hi,

I am extremely new to C++ in the Mac environment.  I  will be soon learning
C++ on a PC at my place of work using Borland C++ and Turbo C++. However, I
have a Mac IIsi at home and would like to learn C++ at home after office
hours.

I am hoping to get a C++ compiler for my Mac and I noticed, as I
browsed throught this newsgroup that there are two commonly mentioned C++
compilers for the Mac, namely MPW C++ and Zortech C++.  It would be nice if
I can run Turbo C++ or Borland C++ (maybe via SoftPC of which I do not know
much about.  I was told it can be slow) so I can be more consistent with my
work.  Has anyone tried that?

I would appreciate any advice on this matter.

Also how can I get MPW C++?  Are there any books out there on programming
with C++ on the Mac?  I checked out the local bookstores but found none.

Thanks in advance.

Josh Lam
Honeywell Inc
[e-mail]

- --
Josh Lam
Honeywell Inc
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jim Leuper)
Organization: Lotus Development Corp.
Date: Mon, 8 Jun 92 16:04:03 GMT

> It would be nice if
> I can run Turbo C++ or Borland C++ (maybe via SoftPC of which I do not know
> much about.  I was told it can be slow) so I can be more consistent with my
> work.  Has anyone tried that?

Hmmm... a comment on the nature of compilers. You might be able to get Turbo
C++ or Borland C++ to run on your Mac under SoftPC, but they won't do what you
are hoping for. They are designed to emit code that will run on IBM PC's,
and they will continue to do so even if you manage to run them on a Mac. This
is what people are speaking of when they refer to cross-compilation.
If you expect to run the programs on your Mac, you will need a native compiler.

> Also how can I get MPW C++?  Are there any books out there on programming
> with C++ on the Mac?  I checked out the local bookstores but found none.

MPW C++ is an Apple product, available from APDA  (Apple Programmers and
Developers Association). Their phone number is 1-800-282-APDA.
I know of at least one book that fits the bill. It is entitled "Elements of
C++ Programming on the Macintosh" (or something reasonably close). It is
published by Addison-Wesley, and I believe that the author's name is
Weston.

- ----------------------------------------------------------------
Jim Leuper                         Lotus Development Corporation
[e-mail]                      Advanced Technology Group
- ----------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Mon, 8 Jun 92 19:22:57 GMT

In article <[e-mail]> [e-mail] (Jim Leuper) writes:
>> It would be nice if
>> I can run Turbo C++ or Borland C++ (maybe via SoftPC of which I do not know
>> much about.  I was told it can be slow) so I can be more consistent with my
>> work.  Has anyone tried that?
>
>Hmmm... a comment on the nature of compilers. You might be able to get Turbo
>C++ or Borland C++ to run on your Mac under SoftPC, but they won't do what you
>are hoping for. They are designed to emit code that will run on IBM PC's,

Has anyone reading done this (gotten Borlanc C++ or another DOS-based
C++ compiler to run under SoftPC on the Mac?  Yes, I know it would produce
code that runs under DOS. I'm just wondering if anyone has successfully
gotten one of these setups to work. Does SoftPC support EMS and XMS memory?

... curious for more than academic reasons...

- --
The essence of OOP: "With all this horse manure, I know there's got to be
                     a pony in here somewhere!"
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Greg Trimper)
Date: 9 Jun 92 04:11:03 GMT
Organization: Enterprise Data Systems Incorporated, Appleton WI

[e-mail] (Paul Potts) writes:

>Has anyone reading done this (gotten Borlanc C++ or another DOS-based
>C++ compiler to run under SoftPC on the Mac?  Yes, I know it would produce
>code that runs under DOS. I'm just wondering if anyone has successfully
>gotten one of these setups to work. Does SoftPC support EMS and XMS memory?

SoftAT does support extra memory, I do not know about SoftPC.  I have
successfully written and compiled programs with Turbo Pascal Pro and
Turbo Vision under SoftAT - I would imagine the others would work as
well.  It is slow, yes, but it also works in the background - doing background
compiles of PC programs on my SE/30 while working in MPW just sorta gives me
a thrill, if you know what I am saying...  smiley.

Also, you CAN install DOS 5 and Win3, if you are careful.  DOn't bother
with Win3 except just as a way to make you Big Blue Friends ooh and ah
over the versatility - it is toooooooo slow to be useable.


Greg Trimper   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: Wed, 10 Jun 92 16:21:53 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Greg Trimper) writes:
>SoftAT does support extra memory, I do not know about SoftPC.  I have
>successfully written and compiled programs with Turbo Pascal Pro and
>Turbo Vision under SoftAT - I would imagine the others would work as
>well.  It is slow, yes, but it also works in the background - doing background
>compiles of PC programs on my SE/30 while working in MPW just sorta gives me
>a thrill, if you know what I am saying...  smiley.

       SoftAT is impressive.  It's so compatible PC viruses can run under it.

       Incidentally, SoftVGA is out for Sparc-based machines.  Macs
may be supported later.

                    John Nagle

---------------------------

From: [e-mail] (Reid Ellis)
Subject: XWindows (was - Towards what purpose A/UX?)
Organization: Alias Research, Inc., Toronto ON Canada
Date: Tue, 2 Jun 1992 04:11:50 GMT

Tim Endres <[e-mail]> writes:
|XWindows is great for the purpose it was intended. I see NO OTHER
|network based windowing system on the planet that compares to X.

Jon W{tte <[e-mail]> writes:
|QuickDraw GX. 'nuff said.

This is the first I've heard of QDGX being "network based".  Has this
been mentioned somewhere and I just missed it?  Developer's Conference
maybe?

Reid

[PS: Follow-ups directed to comp.sys.mac.programmer]
- --
Reid Ellis
[e-mail]        ||           [e-mail]
[e-mail] ||  [phone] [work]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 7 Jun 92 01:03:00 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Reid Ellis) writes:
> Tim Endres <[e-mail]> writes:
> |XWindows is great for the purpose it was intended. I see NO OTHER
> |network based windowing system on the planet that compares to X.

> Jon W{tte <[e-mail]> writes:
> |QuickDraw GX. 'nuff said.

> This is the first I've heard of QDGX being "network based".  Has this
> been mentioned somewhere and I just missed it?  Developer's Conference
> maybe?

QDGX is not network based, thank God. We don't need a yet another slow
graphics system. Whoever thought that sending bitmaps over the network
is a good idea should take a long deep breath.
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 7 Jun 92 01:26:20 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Kent Sandvik) writes:

>In article <[e-mail]>, [e-mail] (Reid Ellis) writes:
>> Tim Endres <[e-mail]> writes:
>> |XWindows is great for the purpose it was intended. I see NO OTHER
>> |network based windowing system on the planet that compares to X.

NeXTStep is also networked... pipe that PostScript over the ether, baby.
- --
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett - personal {opinions,ramblings,hallucinations}
- --
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett - personal {opinions,ramblings,hallucinations}

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 7 Jun 92 03:40:38 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Mark Lanett) writes:
>
> [e-mail] (Kent Sandvik) writes:
>
> >In article <[e-mail]>, [e-mail] (Reid Ellis)
writes:
> >> Tim Endres <[e-mail]> writes:
> >> |XWindows is great for the purpose it was intended. I see NO OTHER
> >> |network based windowing system on the planet that compares to X.
>
> NeXTStep is also networked... pipe that PostScript over the ether, baby.

And NeWS designers also realized that vectorized information is far faster to
pump
over the net than slow bitmaps. Anyway, I personally think that graphics
networking is really not a big issue. This based on the experience seeing
Habitat (one of the first crude virtual reality systems) running over
a 300bps modem, and a Commodore-64 was doing the graphics. It's all in
the protocol, boys and girls. Graphics is best done on the display/CPU
itself. This is something Silicon Graphics also knows.
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Date: 7 Jun 92 09:52:35 GMT
Organization: Whole Earth 'Lectronic Link

In article <[e-mail]> [e-mail] (Mark Lanett) writes:
_>[e-mail] (Kent Sandvik) writes:
_>>In article <[e-mail]>, [e-mail] (Reid Ellis) writes:
_>>> Tim Endres <[e-mail]> writes:
_>>> |XWindows is great for the purpose it was intended. I see NO OTHER
_>>> |network based windowing system on the planet that compares to X.
_>NeXTStep is also networked... pipe that PostScript over the ether, baby.
Silicon Graphics's network version of its "gl" graphic library lets you ship
shaded, lit, 3-d models with textured spline surfaces and Z-buffering over the
net. Kind of hard to do that with either QuickDraw or Postscript.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 Jun 92 03:09:27 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (David
Phillip Oster) writes:
>
> In article <[e-mail]> [e-mail] (Mark Lanett) writes:
> _>[e-mail] (Kent Sandvik) writes:
> _>>In article <[e-mail]>, [e-mail] (Reid Ellis)
writes:
> _>>> Tim Endres <[e-mail]> writes:
> _>>> |XWindows is great for the purpose it was intended. I see NO OTHER
> _>>> |network based windowing system on the planet that compares to X.
> _>NeXTStep is also networked... pipe that PostScript over the ether, baby.
> Silicon Graphics's network version of its "gl" graphic library lets you ship
> shaded, lit, 3-d models with textured spline surfaces and Z-buffering over the
> net. Kind of hard to do that with either QuickDraw or Postscript.

OK, I guess I need to justify why I personally think that distributed graphics
are evil, even if handy in some instances. Imagine user Foo Bar, sitting by
his/her computer, which suddenly starts acting sluggish. The end user will maybe
reboot the machine, or try to shake it, or call the service technician.

Little did they know that a client used CPU cycles over the net for nifty
3-D graphics that the manager needs for his multimedia presentation next
Friday.

It's fine to use such power for special projects, let's say "Industrial Light
and Magic" style graphics shops. However distributed graphics computing is a
little bit
scary as a default setup for office computers. Most end users enjoy the
snappiness
of fast graphics, and they don't want anything happening behind their backs for
decreasing the graphics performance. This is the reason multi-user UNIX systems
never sell/perform well in the office environment (trust me, I looked with my
left
eye when sales reps tried to sell 'em).
- --
                                              Cheers, Kent
PS: Personal comments.


+++++++++++++++++++++++++++

From: [e-mail] (Thad Humphries)
Date: 9 Jun 92 02:27:20 GMT


  KS> From: [e-mail] (Kent Sandvik) Newsgroups:
  KS> comp.sys.mac.programmer Organization: MacDTS Mongols
  KS>
  KS> In article <[e-mail]>, [e-mail]
  KS> (David Phillip Oster) writes:
  KS>

  > In article <[e-mail]> [e-mail] (Mark Lanett)
  > writes:
  _> [e-mail] (Kent Sandvik) writes:
  > In article <[e-mail]>, [e-mail] (Reid Ellis)
  KS> writes:
  > Tim Endres <[e-mail]> writes: |XWindows is great for the purpose it
  > was intended. I see NO OTHER |network based windowing system on the
  > planet that compares to X.

  KS> OK, I guess I need to justify why I personally think that distributed
  KS> graphics are evil, even if handy in some instances.

In the "for what it's worth department, my biggest reason for *not* getting A/UX
(except my savings still thin from all last year's new toys) is the X
environment.  Why do I want a Mac window manager?  I want Unix and X but not if
I can't have Motif.  ICS has Motif for A/UX 2.0 but at a heafty price.  Why
can't Apple bundle an industry standard window manager with development
libraries?

---------------------------

From: [e-mail] (Nigel Stanger)
Subject: SUMMARY: Comparing blocks of memory in Pascal
Date: 5 Jun 92 02:18:10 GMT
Organization: University of Otago, Dunedin, New Zealand

Well, I received lots of replies on how to compare two blocks of
memory, the end result being I now have a function that will work
for arbitrary-sized blocks. The function goes something like this
(thanks to Doug McNaught and Jim Cathey):

  function MemEqual(a,b: Ptr; n:integer):Boolean;
  var i:integer;
      p1,p2:Ptr;
  begin
    p1:=a;
    p2:=b;
    for i:=1 to n do begin
      if (p1^ <> p2^) then begin
        MemEqual = FALSE;
        Exit(MemEqual)
      end else begin
        p1 := Ptr(ord4(p1) + 1);
        p2 := Ptr(ord4(p2) + 1);
      end
    end;
    MemEqual := TRUE;
  end; {MemEqual}

As you can see, it's basically just a Pascal implementation of C
pointer arithmetic. I think you can get away with not using p1
and p2 -- just access a and b directly instead. This assumes of
course that you are passing the addresses of the objects rather
than actual Ptrs, i.e. MemEqual(@obj1,@obj2,size). If you were
passing Ptrs things could get messy later on... :)

However, one proviso to go with this -- as [e-mail]
points out:
> The reason Pascal doesn't support comparing structured types is that
> not all the bits in a record or array are necessarily significant.
> For example:
>
>   type
>     a = record
>         b : boolean;
>         c : char;
>         d : boolean;
>       end;
>
> Acording to Think Pascal this has a size of 6.  Now there are only
> 3 bytes of real data in there so you're left with 3 bytes of rubbish.
> If you do a memory image compare you're going to be mislead, if
> not now then some time soon.
>
> Of course if you stick to nice types like integer, longint, OSType,
> etc (things that are word sized or even multiples thereof) you'll
> be OK.  Things to be careful of are char, byte, signedByte, boolean,
> subranges, and arrays.  Also remember that if you make your records
> packed then all these rules change!

This isn't a problem in my case, as I read the data from a
resource. Although there _is_ an odd byte in there, the ResEdit
template I created for the resource has an FBYT there, which
automatically fills it in zero when I create one. I can see that
this would be a problem in general though. Would blanking (i.e.
fill with zeros) the block of memory beforehand help? I might try
this out and see what happens.

Matt Mora suggested:
> IUMagIDString(aPtr,bPtr:Ptr;aLen,bLen:INTEGER):INTEGER;
>
> It will compare blocks of memory and return a 0 if they are equal else
> it return a 1.

However, Jon Waette (sp?) points out that "IU means that it will
do some strange stuff with international characters..."

Tommy Nordgren suggested using Munger. I had thought of that, but
I've never really sat down and tried to figure what it is that
Munger actually _does_. I seem to remember that it does something
different, but I could be wrong. Oh well... He also suggested
looking at the source code for the HexDump DA -- haven't done
this yet, but will do...

Phil Shapiro suggested EqualMem() from the TCL library. I'd
forgotten about that one -- written in assembly too. It is
limited to 32K, and the size of the object must be even. The big
problem I found with this was actually including it in my project
- -- I seemed to end up needing a whole pile of files in the
project that I didn't really want (this is a non-TCL app BTW).
Maybe I just did it wrong...

That's the options I got, the first option seems to work OK, and
has certainly solved my current problem. Thanks to everyone who
contributed!

- --
See ya
                                Nigel.
- ----------------------------------------------------------------------
Nigel Stanger,                  Internet: [e-mail]
University of Otago,            Phone: [phone]
Dunedin, NEW ZEALAND.           Fax:   [phone]
"I would like to propose a toast -- to the caterers!" -- Rowan Atkinson

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 5 Jun 92 13:39:16 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] (Nigel Stanger) writes:
>
>  function MemEqual(a,b: Ptr; n:integer):Boolean;
>
>Phil Shapiro suggested EqualMem() from the TCL library. I'd
>forgotten about that one -- written in assembly too. It is
>limited to 32K, and the size of the object must be even. The big

    Your homegrown EqualMem is limited to 32K as well, because both
the argument 'n' and the local counter 'i' are 16-bit integers.

    Also, you can get a considerable speed improvement by comparing
more than a byte at a time. Such a function would go something like this:
(it's early, so this may not compile, or even work right, the first time)

function EqualMem(a, b : univ Ptr; blkSize : LongInt) : Boolean;
var
    longCount : LongInt;
    byteCount : SignedByte;

    longIndex : LongInt;
    shortIndex : SignedByte;

{ byteCount is a SignedByte because we're guaranteed that it's 0 <= n <= 3. }

begin
    longCount := blkSize div 4;
    byteCount := blkSize - (longCount * SizeOf(LongInt));

    for longIndex := 0 to longCount - 1 do begin

        if (LongIntPtr(a)^ <> LongIntPtr(b)^) then begin
            EqualMem := False;
            Exit(EqualMem);
        end;

        a := Pointer(Ord4(a) + SizeOf(LongInt));
        b := Pointer(Ord4(b) + SizeOf(LongInt));
    end;

    { at this point, the blocks are still equal, so compare the last
    few bytes }

    for shortIndex := 0 to byteCount - 1 do begin

        if (a^ <> b^) then begin
            EqualMem := False;
            Exit(EqualMem);
        end;

        a := Pointer(Ord4(a) + 1);
        b := Pointer(Ord4(b) + 1);
    end;

    { the blocks are *still* equal, so they compare the same }

    EqualMem := TRUE;
end;

A caveat: if you're comparing two structures (local records, pointers allocated
with NewPtr, handles allocated with NewHandle), this routine is fine. If
you're comparing two random pointers in memory, then you'll have to change
the routine a bit, because it expects the two blocks being compared to
begin on even byte boundaries; if they don't, you'll get an Odd Address
Exception on 68000 machines. This can be avoided by doing a little pre-
processing before the two compare loops, but it does complicate the issue
a bit.

>-- I seemed to end up needing a whole pile of files in the
>project that I didn't really want (this is a non-TCL app BTW).
>Maybe I just did it wrong...

    You did it wrong; EqualMem is a little black box in the TCL,
which doesn't require any other declarations or services; if you just
copy the function into a separate file, you should be able to use
it by itself.

R.



- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Paul G. Smith)
Date: 6 Jun 92 00:39:19 GMT
Organization: CommsTalk HQ


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Nigel Stanger) writes:
> Well, I received lots of replies on how to compare two blocks of
> memory, the end result being I now have a function that will work
> for arbitrary-sized blocks. The function goes something like this
> (thanks to Doug McNaught and Jim Cathey):
>

I missed your earlier posting(s). Here's my solution (MPW Assembler):


    ;---------------------------------------------------------------
    ; FUNCTION EQUAL_MEM(buffptr1: Pointer; buffptr1: Pointer;
    ;                        dataLen: INTEGER;): INTEGER;
    ;---------------------------------------------------------------
    ;
    ;    compares memory: returns 1 if equal, and 0 if not
    ;

EQUAL_MEM:    PROC    EXPORT

        MOVEA.L (SP)+, A1       ; pop return address
        MOVE.W  (SP)+,D0        ; data length
        MOVE.L  (SP)+,D1        ; data address2
        MOVE.L  (SP)+,A0        ; data address1
        MOVEM.L A1/D1-D3, -(SP) ; save return address again

        movea.l    d1,a1            ; copy data address2 into a1
        move.w    d0,d1            ; copy data length
        beq.s    exit            ; skip if zero - result will be set to 0, not equal

        clr.w    d0                ; initialise result to not equal
        subq.w    #1,d1            ; decrement count for DBRA
loop:    cmp.b    (a1)+,(a0)+        ; check string bytes
        bne.s    exit            ; skip out if not equal
        dbra    d1,loop            ; loop if more bytes
noDiffs:
        move.w    #1,d0            ; set result to 1 - strings are equal
exit:
        MOVEM.L (SP)+,A1/D1-D3  ; pop return address again
        MOVE.W    D0,-(SP)        ; save result
        JMP     (A1)            ; & split

    ENDPROC



It's acceptably (ie, very) fast. :-)


best regards, Paul

- -------------------------------------
Paul G Smith / CommsTalk HQ
INTERNET:  "[e-mail]"            CIX:  "pgsmith"
AppleLink: "commstalk.hq" ("[e-mail]")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK

+++++++++++++++++++++++++++

From: [e-mail] (John Wallace)
Organization: TRW Data Systems Center, Redondo Beach, CA
Date: Mon, 8 Jun 92 19:23:49 GMT

In article <[e-mail]> [e-mail] writes:
>
>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Nigel Stanger) writes:
>> Well, I received lots of replies on how to compare two blocks of
>> memory, the end result being I now have a function that will work
>> for arbitrary-sized blocks. The function goes something like this
>> (thanks to Doug McNaught and Jim Cathey):
>>
>
>I missed your earlier posting(s). Here's my solution (MPW Assembler):
>
>
>    ;---------------------------------------------------------------
>    ; FUNCTION EQUAL_MEM(buffptr1: Pointer; buffptr1: Pointer;
>    ;                        dataLen: INTEGER;): INTEGER;
>    ;---------------------------------------------------------------
>    ;
>    ;    compares memory: returns 1 if equal, and 0 if not
>    ;
>
>EQUAL_MEM:    PROC    EXPORT
>
>        MOVEA.L (SP)+, A1       ; pop return address
>        MOVE.W  (SP)+,D0    ; data length
>        MOVE.L  (SP)+,D1    ; data address2
>        MOVE.L  (SP)+,A0    ; data address1
>        MOVEM.L A1/D1-D3, -(SP) ; save return address again
>
>        movea.l    d1,a1        ; copy data address2 into a1
>        move.w    d0,d1        ; copy data length
>        beq.s    exit        ; skip if zero - result will
>                    ;   be set to 0, not equal
>
>        clr.w    d0        ; initialise result to not equal
>        subq.w    #1,d1        ; decrement count for DBRA
>loop:        cmp.b    (a1)+,(a0)+    ; check string bytes
>        bne.s    exit        ; skip out if not equal
>        dbra    d1,loop        ; loop if more bytes
>noDiffs:
>        move.w    #1,d0        ; set result to 1 - strings are equal
>exit:
>        MOVEM.L (SP)+,A1/D1-D3  ; pop return address again
>        MOVE.W    D0,-(SP)    ; save result
>        JMP     (A1)            ; & split
>
>    ENDPROC
>
>
>
>It's acceptably (ie, very) fast. :-)
>
>
>Paul G Smith / CommsTalk HQ
>INTERNET:  "[e-mail]"            CIX:  "pgsmith"
>AppleLink: "commstalk.hq" ("[e-mail]")
>tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
>snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK



You could make it noticably faster (30%) if you recode the inner loop as:

loop:        cmp.b    (a1)+,(a0)+    ; check string bytes
        dbne    d1,loop        ; loop if more bytes
        bne.s    exit        ; if not true, skip setting 1
noDiffs:
        move.w    #1,d0        ; set result to 1 - strings are equal
exit:

Since the dbCC instruction can do the job of both loop control
and condition-code checking, you only have to do the 'bne.s exit'
after you fall out of the loop.


You could also re-code it so that it doesn't use the MOVEM instruction
(since you don't need to put your parameters back on the stack),
and uses the sCC instruction to compute your results.  These will make
especially noticable improvements when comparing only small bits of data:

    ;---------------------------------------------------------------
    ; FUNCTION EQUAL_MEM(buffptr1: Pointer; buffptr1: Pointer;
    ;     dataLen: INTEGER;): INTEGER;
    ;---------------------------------------------------------------
    ;
    ;    compares memory: returns 1 if equal, and 0 if not
    ;

EQUAL_MEM:    PROC    EXPORT

        move.l  (sp)+,d1       ; pop return address
        move.w  (sp)+,d0    ; data length
        move.l  (sp)+,a1    ; data address2
        move.l  (sp)+,a0    ; data address1

        subq.w    #1,d0        ; decrement count for loop
        bmi.s    setResult    ; if length=0, set result to 0
loop:        cmp.b    (a1)+,(a0)+    ; check string bytes
        dbne    d0,loop        ; loop if bytes were equal and
                    ;   there are more bytes to go
setResult:
        seq    d0        ; set to -1 if equal, 0 if not equal
        neg    d0        ; convert to 1 or leave as 0

        move.w    d0,(SP)        ; save result
        move    d1,a0        ; get return address
        jmp     (a0)            ; return

    ENDPROC


You could optimize the above even further by checking for zero-length
compares as soon as you pop dataLen into d0 and jumping to another
return section, but I didn't bother with that above.  There are
probably even more optimizations using long-word compares and the
like, but then you'd have to deal with all of the alignment issues.


Sorry for rambling on so, but I do enjoy optimizing assembly code!

Cheers,
John

- ---
John Wallace    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 9 Jun 92 11:45:44 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Paul G. Smith) writes:
>
>     ;---------------------------------------------------------------
>     ; FUNCTION EQUAL_MEM(buffptr1: Pointer; buffptr1: Pointer;
>     ;                        dataLen: INTEGER;): INTEGER;
>     ;---------------------------------------------------------------
>     ;
>     ;    compares memory: returns 1 if equal, and 0 if not
>     ;
>
> EQUAL_MEM:    PROC    EXPORT
>
>         MOVEA.L (SP)+, A1       ; pop return address
>         MOVE.W  (SP)+,D0        ; data length
>         MOVE.L  (SP)+,D1        ; data address2
>         MOVE.L  (SP)+,A0        ; data address1
>         MOVEM.L A1/D1-D3, -(SP) ; save return address again
>
>         movea.l    d1,a1            ; copy data address2 into a1
>         move.w    d0,d1            ; copy data length
(begin mark)
>         beq.s    exit            ; skip if zero - result will be set to 0, not equal
>
>         clr.w    d0                ; initialise result to not equal
>         subq.w    #1,d1            ; decrement count for DBRA

> loop:    cmp.b    (a1)+,(a0)+        ; check string bytes
>         bne.s    exit            ; skip out if not equal
>         dbra    d1,loop            ; loop if more bytes
> noDiffs:
>         move.w    #1,d0            ; set result to 1 - strings are equal
(end mark)
> exit:
>         MOVEM.L (SP)+,A1/D1-D3  ; pop return address again
>         MOVE.W    D0,-(SP)        ; save result
>         JMP     (A1)            ; & split
>
>     ENDPROC

Here's my alternative to the sequence between (begin mark) and (end mark):

        clr.w    d0        ; clear high byte of result and init cond codes
        bra.s    endloop        ; enter loop at end
loop:        cmp.b    (a1)+, (a0)+
endloop:        dbne    d1, loop
        seq.b    d0
        neg.b    d0        ; result = 1 if equal, 0 if not

Note the way I enter the loop by jumping to the DBxx instruction. This
automatically adjusts for the fact that the termination condition is a count
of -1 rather than a count of zero, while simultaneously taking care of the
case where the length of the block was zero to begin with. See, there _is_
a reason why the DBxx instruction works the way it does.

Also note my use of a DBNE to loop and test for not equal at the same time.
However, since the loop is entered at the DBNE without an initial comparison,
you have to make sure the condition codes do *not* initially satisfy the
termination condition, or the DBcc will just fall through! Thus the CLR
instruction serves the dual purpose of setting the condition code Z bit, and
initializing the high byte of the result at the same time.

It is also possible to use a pair of DBRAs to handle a 32-bit unsigned
count, without sacrificing the speed of DBRA.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (Paul G. Smith)
Date: 9 Jun 92 21:15:53 GMT
Organization: CommsTalk HQ


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John Wallace) writes:
> Sorry for rambling on so, but I do enjoy optimizing assembly code!
>

And I don't, regarding assembler programming as something to do only when
I have to, and not as an enjoyable task at all.

Many thanks for the optimizations! I will make good use of them.

best regards, Paul

- -------------------------------------
Paul G Smith / CommsTalk HQ
INTERNET:  "[e-mail]"            CIX:  "pgsmith"
AppleLink: "commstalk.hq" ("[e-mail]")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK

+++++++++++++++++++++++++++

From: [e-mail] (Paul G. Smith)
Date: 9 Jun 92 21:15:58 GMT
Organization: CommsTalk HQ


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> Here's my alternative to the sequence between (begin mark) and (end mark):
>
>

Keep 'em coming! I'm learning a lot here. :-)

best regards, Paul

- -------------------------------------
Paul G Smith / CommsTalk HQ
INTERNET:  "[e-mail]"            CIX:  "pgsmith"
AppleLink: "commstalk.hq" ("[e-mail]")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK

---------------------------

End of C.S.M.P. Digest
**********************